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COMMENT 


[SSL certificate] 
warnings are a 
nuisance for the same 
reason they may help. 


J 





Chester Wisniewski, Sophos 


SSL CERTIFICATE WARNINGS 
- NUISANCE OR VALUE? 


In a paper entitled ‘Crying Wolf: An Empirical Study 

of SSL Warning Effectiveness’, Carnegie Mellon 
researchers examined the results of a study on user 
behaviour in response to invalid SSL certificate warnings. 
While the paper makes for an interesting read on how 
humans perceive risk, how too much nagging breeds 
disregard, and how the sternness of language used to 
explain the situation changes perception, it mostly leads 
me to wonder what the point of these warnings is at all. 


Primarily, the warnings protect against Man-in- 
the-Middle (MitM) attacks. If you are using a 
non-compromised browser on a non-compromised 
machine and manually enter your online banking URL, 
these warnings could alert you that something is amiss. 
However, I have not heard of anyone going to the effort 
of hijacking SSL sessions in any volume in order to 
execute an attack like this. 


A MitM attack requires the attacker to be able to intercept/ 
redirect the connection between a victim computer and 
an SSL website they are communicating with. If the 
interloper tried to sign a certificate convincing the client 
it was Chase Bank and they were not taking advantage 
of the SSL null byte vulnerability reported last summer 
at Black Hat, then the user would receive a warning that 
the certificate was self-signed or somehow modified. It’s 
certainly possible that this would protect users, but the 
effort required for this type of attack tends to limit the 
number and scale of such attacks. 
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Warnings are a nuisance for the same reason they 

may help. Almost 100% of the time they can safely be 
ignored. If you receive a warning at your online banking 
site, more often than not the warning is because your 
bank’s certificate has lapsed and they have been unable 
to retrieve a new one. This is not something your end- 
users should be concerned about, nor is it something 
they are likely to figure out based on the way browsers 
present the information. 


Why warn your users of something that is not really 
indicative of an attack? This simply leads to the 
“boy-who-cried-wolf’ scenario. Every false warning or 
pop-up undermines all the work you have done as an 
administrator to secure a user’s workspace. The users 
begin to second guess your entire approach and question 
other technologies you have used, and it can have 
consequences outside of the specific application. 


Most attacks are phishing attacks and do not utilize SSL 
to begin with. If the attacker wants to be sure the padlock 
appears in the browser they could simply purchase a 
certificate for their bogus domain — it is trivial to request 
an SSL certificate from many providers. On 22 January 

T looked at approximately 100 phishes in our spam 
queues, and none of them used an https connection. 
Many URLs were obviously bogus, while some tried to 
manipulate the way the browser displayed the domain 
name to trick the user. 


It is my opinion that more effective SSL warnings 

will not improve Internet browsing safety. The 
Carnegie Mellon paper does make an excellent point 
that may be better used in other ways. When designing 
software and choosing which options we present 

to users, we should be careful of how and when we 
interrupt users’ work flow. 


There is value in telling a user that you have blocked 
access to his USB drive, or that an email was blocked 
because multiple credit card numbers were contained 
in an attachment, but when you start sending alarming 
messages to users that they either misunderstand 

or that present them with a problem they cannot fix 
themselves, you start to create a sense that warning 
messages should be ignored. Users want to get back to 
performing the task that was interrupted and we need 
to design our systems to ensure that we only interrupt 
them when it is truly important. 


Security needs to be simple and transparent to be truly 
effective. As an industry we need to rethink how we 
approach the concept of SSL certificates for verifying 
identity. We cannot depend on end-users to understand 
the implications of public key infrastructure and digital 
signatures and make the right choice. 
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NEWS 


RESEARCHERS PAID FOR CHROME BUGS 


Google is inviting security researchers to seek out bugs in 
its Chrome web browser. Researchers reporting genuine 
vulnerabilities to the company will be rewarded with 
$500 per bug, with the reward rising to a maximum of 
$1,337 if the vulnerability reported is deemed by a panel 
to be particularly critical. The company hopes that by 
encouraging external researchers to probe the browser it 
will be able to improve security for its users. “The more 
people involved in scrutinizing Chromium’s code and 
behaviour, the more secure our millions of users will be,’ 
read a posting on the company’s blog. 


The idea of offering rewards for vulnerabilities is not 
new, and in its announcement of the programme Google’s 
Chromium team raised a hat tip to the Mozilla Foundation 
whose Security Bug Bounty Program offers a similar set 
of rewards. 


Bugs in the Chrome and Chromium builds of the browser 
can be reported via an online bug-tracking system. Full 
details can be found in the Google blog at 
http://blog.chromium.org/2010/01/encouraging-more- 
chromium-security.html. 


PHISHING AND SCAMS CONTINUE TO RISE 


According to RSA’s online fraud report for January, the 
number of phishing attacks identified in December was 
three per cent higher than in the previous month. RSA 
reported that, despite an apparent increase in user awareness 
— with 76% of respondents saying that they are familiar 
with phishing — the number of users that have fallen victim 
to a phishing attack is also on the rise. In the company’s 
2007 survey, five per cent of respondents admitted that they 
had been a victim of a phishing attack, whereas in 2009, 
that figure had risen to 29%. Meanwhile, research and 
investigation company Ultrascan claims that 2009 saw the 
highest ever annual losses from 419 fraud. The company 

— which collects its figures based on cases it has analysed 

— estimates that victims around the world lost US$9.3 
billion last year — a rise from $6.3 billion in 2008. 


These reports come as in the UK the Office of Fair Trading 
(OFT) is set to launch a scam awareness month, dubbed 
‘Scamnesty 2010’, aiming to provide consumers with 
information and advice on how to identify scams and how to 
protect themselves. The campaign, which will run throughout 
February, will encourage consumers to deposit suspected 
scam letters in special amnesty bins in public places around 
the country, and to forward email scams to an ‘email bin’. 
The campaign website (http://www.consumerdirect.gov.uk/ 
scamnesty/) also provides examples of scam websites and 
advises consumers as to how to identify such sites as fake. 
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Prevalence Table - December 2009"! 
Malware Type % 
Autorun Worm 8.91% 
Adware-misc Adware 8.15% 
Conficker/Downadup Worm 7.89% 
VB Worm 6.381% 
OnlineGames Trojan 4.51% 
FakeAlert/Renos Rogue AV 4.21% 
Agent Trojan 4.17% 
Heuristic/generic VirusAworm 3.77% 
njec Trojan 3.74% 
Delf Trojan 3.71% 
Virtumonde/Vundo ojan 3.47% 
WinWebSec Rogue AV 3.03% 
Istbar/Swizzor Trojan 2.83% 
Virut Virus 2.81% 
Alureon Trojan 2.51% 
Crypt Trojan 94% 
HackTool PU 1.88% 
Small Trojan 1.86% 
Zbot Trojan 81% 

upigon Trojan 1.81% 
Downloader-misc Trojan 1.70% 

euristic/generic Trojan 10% 
Bifrose/Pakes Trojan 0.89% 
Tanatos Worm 0.89% 
Peerfrag/Palevo Worm 0.88% 
Sality Virus 0.88% 
Crac PU 0.85% 
Wimad Trojan 0.80% 
Themida Packer 0.70% 
PCClient Trojan 0.60% 
Wintrim Trojan 0.60% 
BHO/Toolbar-misc Adware 0.58% 
Others?! 10.61% 
Total 100.00% 
"This month's prevalence figures are compiled from 
desktop-level detections. 
1Readers are reminded that a complete listing is posted at 
http:/Awww.virusbtn.com/Prevalence/. 
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MALWARE ANALYSIS 


CUT THE CUTWAIL 


Kyle Yang 
Fortinet, USA 


After playing the cat-and-mouse game with AV companies 
for several months, the author(s) of Pushdo/Cutwail finally 
decided to change their advanced installer — previously 
codenamed ‘Siberia’ (as per the project name extracted from 
debugging strings in the binary) — to a brand new piece 
codenamed ‘Revolution’. The changes mainly concern the 
communication mechanism between the servers and bots. 
More specifically, the mechanism changed from a direct 
communication mode using the HTTP GET method (single 
packet request) to a sophisticated two-way communication 
mode between servers and bots. In this paper, we will reveal 
the details of this new protocol. 


WHEN AND WHY IT CHANGED 


As far as we know, the Cutwail spam botnet used to seed its 
own executable, which usually came without an obfuscation 
layer. Then, around the end of October 2009, Cutwail began 
to seed Pushdo binaries via the infamous DHL/UPS email 
seeding campaign. This time it came with an obfuscation 
layer in order to dodge AV detection. Among the binaries 
was a new version string, codenamed ‘Revolution6’ 

— possibly indicating six major updates. Previously, this 
number only reached two (‘Siberia2’) — which suggests 
that the author(s) may have spent more time on this 

major update. On reversing its binary, we found that the 
author(s) had put a tremendous amount of work into the 
communication protocol, which is now both more complex 
and robust, and of course stealthier than the previous one 
(thanks to a custom packer made from a custom stub and 
UPX). As for what drove this change, it must certainly have 
something to do with the fact that the Pushdo binary and 
the previous communication protocol had been around for 
a long time, and were well known by AV companies. For 
instance, its critical communication packets were blocked 
by IPS systems. This would have disrupted the attackers’ 
business model on a large scale, preventing them from 
making easy, dirty money. 

Looking at our statistics, we can see that Pushdo very 
rapidly became one of the most prevalent threats running 
from October 2007 to March 2008. It is interesting to 

note that the original HTTP GET communication was 
slightly modified in December 2007 [1] to avoid detection, 
but seemed to quickly be thwarted as activity became 
significantly reduced from March 2008 onwards. 


Until recently, Pushdo activity failed to return to the 
levels experienced during its initial outbreak. In October 
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Figure 1: Initial Pushdo seeding (HTTP GET). 








2009 we observed tremendous activity with the updated 
version: nearly ten times the level detected two years 

ago. This signifies an aggressive approach to seed a new, 
revolutionized version of the Pushdo malware installation 
system. Indeed, the gang behind Pushdo must have quite 
some resources at their fingertips with the ability to seed in 
such high volume. 
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Figure 2: Pushdo/Cutwail — first gen vs. next gen. 


The Revolution6 version is marked by debug ASCII strings 
in the unpacked binary, showing a ‘pdb’ filepath. PDB 
(program database) files contain debug and project state 
information for builds. In this case, the filepath shows the 
project name and debug name, for instance: ‘f:\\programs\\ 
revolution6\\loader\\objfre_wxp_x86\\i386\\Loader.pdb’. In 
some samples, while the project name remained the same, 
the volume changed (e.g. ‘c:\\programs’ ), indicating that 
there was more than one build. 


WHAT CHANGED 


There are two main changes in the Pushdo payload. Firstly, 
in the main routine there is now a condition that leads the 
malware to delete itself and exit when the OS language is 
Russian. This is not uncommon: for instance, Conficker 
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avoids infecting Ukrainian systems, and various Scareware 
flavours do the same. In fact, there might be some connection 
between the Conficker and Pushdo/Cutwail gangs, although 
the nature of that connection remains a mystery. 


The other radical change concerns the ‘injection’ code, the 
main function of which is to control the communications 
between the servers and the bots, for the purpose of 
retrieving all the malware modules (rootkit component, 
mailer component, etc.) that characterize the Cutwail 
botnet. Let’s take a closer look at this process. 


Nowadays, the communication channels of most infamous 
botnets are encrypted, either using a public encryption 
algorithm (e.g. AES-CBC, Base64 in Waledac, etc.) or a 
custom, private one. Pushdo is no exception; it resorts to 
many custom encryption algorithms, leveraging two main 
encryption/decryption keys stored in memory. Figure 3 
shows the stored key pattern. 
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0000 00 00 00 00 00 00 00 





0/00 00 00 00 4£ £6 40 BBIB1 19 BF 44 00 00 00 00|.... NHi# #8 
0/E0 C7 09 00 00 00 00 00 09 00 00 00 00 00 OO OO|nE 
0/00 00 00 00 11 00 00 O00 09 00 78 CB 09 00 AO CB 
00/09 00 CB CB 09 00 FO CB 09 00 18 CT 09 00 40 CT)... 
0/09 00 68 C7 09 00 90 C7 09 00 BS C7 09 00 00 00). .h? 
0/00 00 00 00 00 00 00 00 00 00 00 00 00 OO OO OO 
30/00 00 00 00 00 00 00 00 00 00 00 00 00 00 O0 O0).. 
40/00 00 00 00 00 00 00 00/00 00 00 00 00 oO Oo OO 




















Figure 3: Encryption/decryption key. 


The data circled in red is the key for encrypting/decrypting 
the Pushdo communication packet ‘header’ (made up of 

a start identifier and content length — eight bytes total). It 
should be noted that this key is hard coded in the Pushdo 
binary. Even more interesting is the fact that, based on 

the samples retrieved from different sources/spreading 
methods, this hard-coded key has never changed across 
samples. This explains why Pushdo doesn’t have a routine 
to communicate the key to the server — the server already 
knows it. This is quick and efficient, and saves the cost 

of implementing a ‘safe’ exchange of symmetric keys via 
public key encryption schemes. But 
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randomly rather than pre-shared, the key must be sent to the 
server (see Figure 4 below). 


1. Sending random encryption/decryption 
key to the server 





fj Internet Protocol, src: 192.168.198.128 (192.168.198.128), Dst: 222.138.109.99 (222.138. 109.99) 
If] Transmission Control Protocol, Src Port: ftranhc (1105), Dst Port: http (80), Seq: 1, Ack: 2, Len: 8 
| Hypertext Transfer Protocol 

i Data (8 bytes) 


Data: 0100000037: 
[Length: 8] 






















Ic 29 ad c7 08 00 45 Of 
24 43 cO a8 c6 80 de 8a 





020 6d 63 0. 
030 fa fo 2 


2a 7c 5f 6f 76 75 50 18 
0 00 00 37 8a 3a 26 








BES 
tun 
3 
~~ 
a 
an 
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Figure 4: Sending encryption/decryption key to the server. 


As can be seen above, the random key is sent to the server 
in plain text. 


2. Sending bot and loader info to the server 


The data shown in Figure 5 below is the ‘clear-text’ data 
block generated by Pushdo, which we ‘intercepted’ in 
memory prior to encryption. It appears that every data 
piece starts with the tag ‘PROP’. This looks familiar, and is 
similar to the XML format used by Waledac. The difference 
is that Pushdo has dropped the ‘<tag></tag>’ pairs in order 
to reduce the packet length and make the communication 
faster. Moreover, Pushdo will only send data containing 
the fields ‘Idrver’ and ‘winver’ to the first server it connects 
to (i.e. even if the rest of the communication fails, thus 
warranting an attempt to connect to another server, these 
will not be re-sent). 


Let’s break the whole data block into ‘fields’ for better 
comprehension. The two first fields are the ‘header’, 








of course it is tremendously lacking in OES C0 20. 72 
flexibility, putting the botnet at risk once | 09983670 69 71 
the hard-coded key has been discovered | 00083689 90 00 
(although, as we will see later, this only QOS C20) Ese 
concerns the packet headers). peogsend™ de. 7s 

000836B0 50 19 
The data circled in blue is 000836C0 72 00 
the return value of a call to 000836D0 08 00 
QueryPerformanceCount, an API 000836E0 4F 50 
function frequently used to generate 000836FO 65 72 
pseudo-random values. This data will 90083700 00 07 
be used as the key for encrypting/ DOOR anaes x 08 
decrypting the Pushdo communication ——E 


4F 


00 
00 
00 
65 
00 
a 8 
02 
19 
00 
00 
00 
56 


50 1B 00 00 00 16 00 05 00 08 00 75 6E PROPs...o.0.c.un 
Cl 84 5D 78 B7 98 9D 24 50 52 4F 50 18 iq. @]x#?PROPs 

14 00 06 00 04 00 63 6F 75 6E 74 00 00. ...0.0.0.count.. 
50 52 4F 50 1A 00 00 00 14 00 08 00 04 ...PROPs...0.0. 
73 73 69 6F 6E 00 E8 Fl CE EA 50 52 4F_ .session. ff PRO 
00 00 14 00 07 00 04 00 76 65 6E 64 6F Po...0.0.0.vendo 
00 00 00 50 52 4F 50 18 00 00 00 12 00 r.o...PROPs...0. 
00 6C 64 72 74 79 70 65 00 01 00 50 52 a.0.ldrtype.o.PR 
00 00 00 14 00 07 00 04 00 6C 64 72 76 OPs...0.0.0.ldrv 
37 00 00 00 50 52 4F 50 28 00 00 00 19 er.7...PROP(...5 
13 00 77 69 6E 76 65 72 00 05 00 00 00 .o.o.winver.o... 
00 28 OA 00 00 03 00 00 00 00 O01 01 52 a...(...0....00R 
08 00 00 00 ECVo... 








packet ‘content’. Being generated 


Figure 5: Clear data block sent from UPS/DHL spam sample. 
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encrypted by the pre-shared key, while | 00000000 50 52 4F 50 1B 00 00 00 16 00 05 00 08 00 75 GE PROP.......... un 
the rest is the ‘content’, encrypted by 00000010 69 71 00 37 08 64 EO 4E OC 13 84 50 52 4F 50 18 igq.7.daN..,,PROP. 
the random key. 00000020 00 00 00 14 00 06 00 04 00 63 6F 75 GE 74 00 00 ......... count.. 
00000030 00 00 00 50 52 4F 50 1A 00 00 00 14 00 08 00 04 ...PROP......... 
There are two main pieces of 00000040 00 73 65 73 73 69 6F GE 00 76 D2 2A 59 50 52 4F .session.vO*YPRO 
information in this data block. One 00000050 50 19 00 00 00 14 00 07 00 04 00 76 65 GE 64 GF P.......... vendo 
is the basic host-related information, 00000060 72 00 10 00 00 00 50 52 4F 50 18 00 00 00 12 00 r..... PROP...... 
: : : : 00000070 08 00 02 00 6C 64 72 74 79 70 65 00 01 00 50 52 ....ldrtype...PR 
including volume information, system 
: : : 00000080 4F 50 19 00 00 00 14 00 07 00 04 00 6C 64 72 76 OP.......... ldrv 
bios date, video bios data, processor 00000090 65 72 00 37 00 00 00 50 52 4F 50 28 00 00 00 19 er.7...PROP(.... 
model, OS ID and Windows version. 000000A0 00 07 00 13 00 77 69 6E 76 65 72 00 05 00 00 00 ..... winver..... 
000000B0 01 00 00 00 28 0A 00 00 03 00 00 00 00 01 01 52. ....(.... eee R 


The other is the (malware) loader 





oo00000ocOo 45 43 56 08 00 00 00 00 00 00 00 00 00 00 00 00 ECV............. 








information, including loader type, 
loader version and vendor number. 
The latter is very interesting, as 

we are about to see. First, note that this data block is 


Figure 6: Clear data block sent from Bredolab downloaded Pushdo. 


what changes in the information reported to the server by 





























generated from a sample which is the attachment of a fake the loader. 

UPS/DHL email. Now, let’s compare it with data from Figure 6 shows the data sent to the server by a loader 
other samples with different spreading methods to see seeded by Bredolab. The code shown in red highlights an 
Start Data Key word Key word Content Key word (00 Content Description 

identifier length (dd) | identifier length length (dw) | ending) 
(dd) (dw) (dw) 
50524F50 | 1p i 4 é 75 6E 697100 | C1845D 78 B7 a 
PROP uniq 98 9D 24 caeaeet 
system info 
63 6F 75 6E 
50 52 4F 50 send packet 
PROP 18 14 6 4 74 00 00 00 00 00 sins 
count 
7B 6573 73 69 fandom 
50 52 4F 50 number to 
PROP 1A 14 8 4 6F 6E 00 E8 Fl CE EA identify the 
session : 
connection 
76 65 6E 64 6F 
50 52 4F 50 hard-coded 
PROP 19 14 7 4 72 00 11 00 00 00 in Pushdo 
vendor 
6C 64 72 74 79 
50 52 4F 50 hard-coded 
PROP 18 12 8 2 70 65 00 01 00 <4 Bushido 
ldrtype 
6C 64 72 76 65 
50 52 4F 50 hard-coded 
PROP 19 14 7 4 72 00 37 00 00 00 «a Pushdo 
Idrver 
05 00 00 00 01 : 
50524F50 | 49 i 4 re : BETES | 9600 OO 280A.) “ION 
a ; 0000.03.00 | version 
en 00 00 01 01 ae 
end of the 
seen 08 N/A N/A N/A N/A N/A packet 
RECV 
content 





























Table 1: Clear data block structure and description. 
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interesting difference: the vendor number is 0x10 in this 
sample (rather than Ox11 in our UPS sample). So what is 
this vendor number? 


Based on the semantics of ‘vendor’, and on the observations 
above, it could be some sort of affiliate ID, used to 
remunerate partners who distribute the malware. In any 
case, it also has a practical purpose here: it indicates which 
method to use to get and inject the corresponding rootkit 
and mailer modules. 


Specifically, vendor 0x11 determines that they are loaded 
from multiple TCP streams and a report is sent back to 

the server. Meanwhile, under vendor 0x10 they are loaded 
in a single TCP stream and no report is sent back to the 
server. The fact that this vendor number is hard coded 

in the Pushdo binary indicates that the author(s) made 
independent/custom/private binaries for different ‘vendors’; 
in the process, they introduced a new operation mode — rush 
mode (more on which later). 


In order to better reveal the different server responses which 
could be possible based on the ‘vendor’, we carried out 
some fuzzing on the Pushdo request packet (more details 
later). 


After generating this data buffer for the server, Pushdo will 
encrypt it prior to sending it. As we have hinted before, the 
encryption routine has two separate phases. One uses the 
hard-coded key to encrypt the start identifier and data length 
(‘header’). The other uses the randomly generated key that 
has already been sent to the server to encrypt the rest of the 
data (‘content’). 


Encryption algorithm A: encrypt start identifier and data 
length 


In this case, the ‘Start Identifier’ and ‘Data Length’ are 
simply XORed with the hard-coded key. 


For example: 


50 52 4F 50 1B 00 00 00 * 45 9A B3 61 8E 20 3F 19 = 
15 C8 FC 31 95 20 3F 19 


52 45 43 56 08 00 00 00 * 45 9A B3 61 8E 20 3F 19 = 
17 DF FO 37 86 20 3F 19 
As mentioned previously, the key is likely pre-shared with 
the server (albeit the server could get this encryption key 
simply by XORing the original data (50524F501B0000) 
with the encrypted data received from the bot). 


Encryption algorithm B: encrypt rest of data 


In this case, the first three bytes of the randomly generated 
key are used. For each byte of data to encrypt, the 
remainder of the quotient “byte offset / 4’ is computed, and 
its value is the index of the encryption operation to apply to 
that byte. 
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For example: 
Key: 37 8A 3A 


Offset % 4 Method 

0 Byte “ 37 

1 Byte - 8A 
2 Byte + 3A 
3 Byte * (3A + 8A) 

Table 2: Data encryption algorithm. 
Original data: 16 00 05 00 08 00 75 6E 


Encrypted data: 21 76 3f c4 3f 76 AFAA 
























































The encrypted block is then sent to the server. The 
interesting thing is that the server could use the Volume 
Info in the ‘uniq’ to identify whether the bot is running 
under a virtual machine environment, but it seems to 
ignore this. 


3. Retrieving other components 


There are two possible kinds of reply from the server, 
which are identified by their ‘start identifier’. Those with 
‘PROP’ as a start identifier contain the server list. Pushdo 
will update its list based on this message. Those with 
‘FILE’ as a start identifier contain other components, 
including rootkits and the spam engine. As mentioned 
before, Pushdo has two operation modes for retrieving 
those (based on the vendor number): stepping mode and 
rush mode. 


Stepping mode 


Just as its name implies, in stepping mode Pushdo will 
retrieve the rootkit and spam engine step by step, one by 
one. More specifically, it will send the bot status back to 
the server to determine the next step after every module/list 
retrieved (see Figures 7-9). 


Table 3 breaks down the whole data block into fields. 


The retrieved message process routine depends on the 
“TMP file determiner’ and ‘file type identifier’. If the ‘file 
type identifier’ equals 1, then it will check the “TMP file 
determiner’. If a result of 1 occurs after a logical AND, 
a temporary file will be created before injecting into a 
suspend mode svchost.exe. Otherwise, it will be injected 
directly into a suspend mode svchost.exe, but it will 
always perform a sanity check before the injection. The 
svchost.exe process info will be stored in the memory 
and a partial file checksum value will be used when 
reporting bot status. Figure 10 shows the structure of the 





bot status info. 
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Type Start TMP file File type | File Content | Key word (00 Ending) Content 
identifier determiner identifier |length _| identifier 
(dd) (dw) (dw) (dd) (dd) 


















Rootkit 
installer 


52 6F 6F 74 4B 69 74 5F 31 37 00 00 
RootKit_17 


46 49 4C 45 
FILE 






0x9224 0x9200 | 0x34 N/A 








4D 61 69 6C 65 72 5F 52 53 31 5F 65 
6D 70 74 79 00 00 
Mailer_RS1_empty 








46 49 4C 45 
FILE 






Spam 
engine 





Ox45E2A | 0 1 Ox45E00 | 0x12 N/A 


4D 61 69 6C 65 72 5F 52 53 31 SF 37 
38 5F 31 35 39 SF 31 32 31 SF 34 31 28 
44 69 6D 61 72 69 6B 29 00 
Mailer_RS1_78_159_121_41(Dimarik) 
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Table 3: FILE message structure. 
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Figure 10: Bot status data — one process (rootkit installer) running. engine to spread itself. 
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Figure 11: Clear report data block. 


FUZZING PUSHDO BOTNET REQUEST 
PACKET 


The main purpose of this part of the paper is to reveal 

the relationship between different vendor ID and server 
responses, and to gain an idea of how many custom/private 
Pushdo binaries there are now, by fuzzing the vendor 
value. 


Method: We use protocol re-writer to customize the 
vendor value before it sends out, then intercept the response 
packets. 


The vendor ID with corresponding server response will be 
the following (partial): 
Rootkit_[number] represents the “Key Word’. 
Loader_VOx[number] represents the Pushdo binary with 
hard-coded vendor ‘number’ 
Vendor=0x00, downloaded Modules: 
Rootkit_1, Loader_VOx01, Mail Sniff, Filter 
Vendor=0x01, downloaded Modules: 
Rootkit_1, Loader_VOx1, Mail Sniff, Filter 
Vendor=0x02, downloaded Modules: 
Rootkit_2, Loader_VOx2 
Vendor=0x09, download Modules: 
Rootkit_9, Loader_VOx9 
Vendor=0x10, downloaded Modules: 
Rootkit_16, Spam Engine 
Spam Engine served for Bredolab. 
Vendor=0x11, downloaded Modules: 
Rootkit_17, Spam Engine 
Spam Engine served for Pushdo itself. 
Vendor=0x12, downloaded Modules: 


Rootkit_18, Loader_V0x12, Spam Engine 
Spam Engine served for ??? 


Rootkit_21, Loader_VOx15, 

Spam Engine 

Spam Engine served for ??? 
Vendor=0x 16, downloaded Modules: 
Rootkit_22, Loader_V0x16, Spam Engine, Web Mailer 
Spam Engine served for ??? 


Vendor=0x17, downloaded Modules: 
Rootkit_23, Loader_V0x17, Spam Engine 
Spam Engine served for ??? 


Vendor=0x 18, downloaded Modules: 
No Modules downloaded. 


Vendor=0x 19, downloaded Modules: 
No Modules downloaded. 


Vendor=0x1A, downloaded Modules: 
No Modules downloaded. 


Vendor=0x1B, downloaded Modules: 
Rootkit_1, Loader_V0Ox01, Web Mailer 


Vendor=0x20, downloaded Modules: 
Rootkit_1, Loader_V0Ox01, Web Mailer 


Vendor=0x63, downloaded Modules: 
Rootkit_1, Loader_VOx1 


Vendor=Oxfd, downloaded Modules: 
Rootkit_1, Loader_VOx01 


Vendor=Oxfe, downloaded Modules: 
Rootkit_1, Loader_VOx01, Web Mailer 


Vendor=Oxff, downloaded Modules: 
Rootkit_1, Loader_VOx01 


Vendor=0x 100, downloaded Modules: 
Rootkit_1, Loader_VOx01 


Vendor=Oxfffe, downloaded Modules: 
Rootkit_1, Loader_V0Ox01, Web Mailer 
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Vendor=Oxffff, downloaded Modules: 
Rootkit_1, Loader_VOx01 


Vendor=Oxffffff, downloaded Modules: 
Rootkit_1, Loader_VOx01 


Vendor=Oxffffffff, downloaded Modules: 
Rootkit_1, Loader_VOx01 


From the above fuzzing results (gathered 18 December 
2009), we can see that both the rootkit and loader version 
number is related to the vendor ID. There may also be 23 
private/custom Pushdo binaries based on the different hard- 
coded vendor IDs. As mentioned previously, the vendor 
may be related to the partners who distribute the malware. 
In this case we only revealed two: 0x10 and 0x11, but there 
are still more to be revealed. We have even seen some new 
modules with another new project name: ‘webbot’. The 
debug build has now reached three, “‘WebMailer3’. After 
reversing this binary, it appears to still be experimental and 
that the author(s) are still trying to debug it since there is a 
‘/debug’ switch. Fortinet’s FortiGuard Labs has dubbed this 
new engine ‘Webwail’. Webwail has the ability to register 
new email accounts and send spam from the web. Around 
15 January 2010, Pushdo started to download this new spam 
engine, spreading Webwail with the help of its old friend 
Bredolab once again. At the time of writing, Webwail is 
registering Hotmail accounts [2]. 


DETECTION 


Thanks to its well-organized data structure, Pushdo can 
communicate a large amount of information from and 
to its command and control server. We can read that 
information as well, the only issue being the encryption 
key. However, the encryption key doesn’t change even 
in custom/private builds for other malware, thus making 
detection easier. 


REFERENCES 


[1] SecureWorks. http://www.secureworks.com/ 
research/threats/pushdo/. 


[2] More information on Webwail can be found at 
http://blog.fortinet.com/bredolab-gearing-up-to- 
spam-the-web/. 


[3] More information on Pushdo/Cutwail can be 
found at http://www.fortiguard.com/analysis/ 
pushdoanalysis.html. 


[4] More information on Crime Services can be found at 
http://blog.fortinet.com/adaptive-crime-services/. 
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DATA TAINTING FOR MALWARE 
ANALYSIS -— PART THREE 


Florent Marceau 
CERT-LEXSI, France 


In this three-part series Florent Marceau studies the use 
and advantages of full virtualization in the security field. 
Following an introduction to full virtualization (see VB, 
September 2009, p.6), and a look at the limitations of the 
technology (see VB, November 2009, p.8), the third and 
final part looks at the implementation of the technology. 


IMPLEMENTATION 


Our mechanism of data tainting as described previously 
will be the engine of our project. Every byte of RAM will 
have a tag in the taintmap. As we have seen previously, 
each byte received from the network (in order to 
characterize the configuration file) will be marked and 
propagated. This propagation is guaranteed in RAM as 
well as on the hard drive. Every malware sample we wish 
to analyse will be loaded from a virtual CD; therefore we 
will taint any data coming from the CD in order to mark 
the binary image to be analysed. This way, the code and the 
binary data of the malware are tainted at the outset. When 
the binary unpacks itself, the tainted code of the unpacker 
will read its similarly tainted data in order to generate 

the viral code — which will also be tainted thanks to the 
propagation mechanism. 


1.1 Taint mark differentiation 


Since we use a tag size of one byte, we can use eight 
different bit flags. These flags will be used to differentiate 
between the tainted data that originates from the network 
and the data loaded from the disk or the CD. 


This simple scheme allows us to distinguish network 

data from the data that is already present in the system. 
However, when data is manipulated by the malware code, 
it may be combined with the hard drive tainted data. Which 
flag should persist then? We need to define a persistence 
policy for tags. If data received from the network is saved 
immediately to the disk for further processing, it must 
keep its network taint mark and not that of the hard drive. 
Meanwhile, a tainted piece of hard drive data will never 
acquire the network tag (indeed, for our purposes, outgoing 
traffic is of no interest). 


1.2 Data dumping 


The final part of our implementation is the dumper code. 
The goal here is to capture all data from the network that 
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has been manipulated by a piece of tainted code (regardless 
of the code’s mark of origin). This allows us to characterize 
an unciphered configuration file. 


The dumping code must reside in a place where the data 
flow can easily be controlled. We implement it as MMU 
hooks in order to control all reading and writing exchanges 
between the RAM and the CPU. These hooks must be 
placed and executed just before the legitimate operation; 
in this way, in the case of a write operation, we can check 
the data that will be written as well as the data that will be 
overwritten. For performance reasons, this code must be 
optimized (written in inline assembly) since its execution 
will involve a virtual RAM access latency that will have a 
heavy impact. 


We introduce here the use of another bit of the tag to 
distinguish between tainted data that has been manipulated 
and other, intact tainted data. We define manipulated data 
as any tainted data written in RAM from a piece of tainted 
code. The manipulated bit is not like the other flags that 
are used to distinguish the data’s origin (network or drive). 
The only purpose of this bit is to trigger the dumping 
mechanism. When a piece of tainted data is written from 

a given piece of tainted code, this data will be marked as 
manipulated. Subsequently, any access of this manipulated 
data area (reading or writing) will trigger the dumping 
mechanism. This will dump the data area in an output file 
and then delete the manipulated bit (but not the origin 
marker). Thus, the manipulated bit is not persistent (and 

is not propagated) in order to minimize redundancy in our 
dump file. This also allows the dump size to be limited and 
ensures that each layer of decryption and decompression 
will be captured. 


To summarize, in RAM we now have the original tainted 
data (from the network or from the disk), and among this 
data, some has been manipulated by tainted code and is 
marked as such. 


Now we only have to make the dumping logic as 
exhaustive as possible. For this, we chose the following 
implementation: 


- Ona write access (CPU -> RAM) (an overwrite case) 
from a non-tainted piece of code (such as a part of the 
OS): if the target address in RAM is tainted and has 
been manipulated, we capture it in a ‘net_dump’ file if 
it consists of network data, and otherwise we capture it 
in an ‘other_dump’ file. 


- Ona write access (CPU -> RAM) (an overwrite case) 
from a tainted piece of code (such as the malicious 
code): if the data to be written in RAM is tainted, we 
add the manipulated bit to its flag. For the data to be 
overwritten, as previously, if the target address in RAM 
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is tainted and has been manipulated, we capture it in 
a ‘net_dump’ file if it consists of network data, and 
otherwise we capture it in an ‘other_dump’ file. 


- Onaread access (RAM -> CPU): if the data to be 
read in RAM is tainted and has been manipulated, we 
capture it in a ‘net_dump’ file if it consists of network 
data, and otherwise we capture it in an ‘other_dump’ 
file. 


In order to improve the efficiency and readability of the 
dump, the dumping mechanism will dump the data and 

all other tainted data that are contiguous with it. For this 
purpose, the dump mechanism scans the memory from the 
targeted addresses to the lower addresses of the tainted data, 
thereby determining the lower boundary of the dump area. 
The upper boundary will be determined in the same way so 
that we know the exact dumping scope. 


Figure | illustrates the dumping process. 


1.3 Limitations of the dumper mechanism 


The dumping mechanism is not perfect, and is not our ideal 
choice, but the mechanism has to be as effective as possible 
for a maximum number of samples (an empirical approach). 
Let’s consider a decryption algorithm such as: 

( ) lea esi, [data] 
mov ecx, SIZE 
decode: 


mov eax, [esi] 


mov [esi] ,eax 


1 


( 
( 
( 
( 
( 
( add esi,3 
( 


) 
) 
) 
) xor eax, 0xd3adc0de 
) 
) 
) 


loop decode 


This simple code will decode the data with a xor opcode 
using the key Oxd3adcOde. The problem here lies in (1) 

—at each iteration the different decoded zones overlap 
themselves. With the previous implementation of our 
dumping mechanism, during the first iteration, the first 
three bytes of the string would be dumped in clear text, with 
the fourth byte not yet decoded. The fourth byte would be 
decoded and dumped again only at the second iteration. The 
results here would then be the dump of the clear text string, 
yet every three bytes the text would be discontinued by a 
garbage data byte. Other examples are possible; there is no 
absolute solution here, we just have to find the one that will 
be the most effective. 


1.4 Empirical observations 


This project was put into practice two years ago. Regular 
monitoring of valid codes clearly shows that our main 
obstacles are the use of particularly heavy obfuscation 
and new virtual machine detection techniques. If we 
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Figure 1: Within RAM we have tainted data that originates 
from the network or from the different volumes. An 
operation from a piece of tainted code (1), such as reading 
network data (2) in order to apply some arithmetic 
processing to it, leaves this data tainted on registers. When 
storing it in RAM, the dumper (3) adds the ‘modified’ mark 
(4). Later, whatever the origin of the operation (5), any 
accessing of the previous data (read / write) (6) triggers 
the dumper mechanism to evaluate the size of the modified 
tainted data (7), and then remove this modified mark to 
finally dump the data in its output file (8). 





Manipulated 


consider the global evolution of banker trojans we can 
conclude that there has been a great advancement in the 
malicious techniques used. Many have embedded ‘kernel 
rootkit’ capabilities, which won’t impact our solution, 
but the use of increasingly sophisticated packers and 
complex encryption algorithms may become a problem. 
We rarely find malware with anti-tainting capabilities, 
although anti- VM methods have become common. Thus, 
an implementation of data tainting that is limited to 
‘explicit direct flow’ propagation is currently still sufficient 
(although this could change if there is an increase in 

the number of automated analysis platforms based on 
data tainting). 


2. RESULTS 


In this section we look at the results of applying our data 
tainting mechanism to real-world malware. 


2.1 Torpig/Sinowal family 


The configuration file for this piece of malware is the same 
for all samples and uses a weak encryption (xor) with a 
constant key. 


The interest here is purely technical, more than a year 

ago the first versions of our platform were 100% effective 
against this malware family. However, with the emergence 
of a newer variant using the MBR rootkit Mebroot/MaOS 
[1], the encryption applied by the rootkit (on the rootkit 
itself and its downloaded files) became so strong that the 
code propagation tended to be lost. Unfortunately (or 
perhaps fortunately), this variant was available for only a 
short period of time and was rapidly taken offline. Thus, we 
didn’t have time to complete our tests on this sample. 


A new active sample of Torpig/Mebroot was found in 
April, which we were able to test on our platform. Results 
showed that, despite the heavy encryption and the rootkit 
deployment stage, our implementation of the data tainting 
mechanism, while significantly slowed, was fully effective. 
The results are shown below: 


MDS: d438c3cb7ab994333fe496ef04£734d0 
Hard drive dump file size: 1.2G 
Network dump file size: 283M 


We then get the following dll configuration on the network 
dump file: 


Cie 208) 
?{balr}pbb, ?pa~eps}tJO/L:/1lbeh}t,gxbxsx}xeh+yxuut 
66.29.115.68 


66.29.115.68 
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*lukb.ch *zkb.ch *bank.ch *bcvs.ch *bcge.ch 
banking.*.ch *vontobel.com *ubp.ch *sarasin.ch *hbl. 
ch *directnet.com *arabbank.ch *baloise.ch 


*alpha.gr *bankofcyprus.gr *marfinegnatiabank.gr 
*winbank.gr *eurobank.gr *nbg.gr *millenniumbank.gr 
*piraeusbank.com *emporiki.gr 


*centralbank.gov.cy *bankofcyprus.com *laiki. 
com *usb.com.cy *hellenicbank.com *coopbank.com.cy 
*universalbank.com.cy 


*uno-e.com www*.bancopopular.es www.bv- 
i.bancodevalencia.es oi.cajamadrid.es 


net.kutxa.net telemarch.bancamarch. 

es *bancocaixageral.es *caixagirona.es www. 
caixacatalunya.es *bbva.es *bbvanetoffice.com 
telemarch.bancamarch.es 


bancae.bancoetcheverria.es lo*.lacaixa.es www. 
cajacanarias.es areasegura.banif.es seguro.cam. 

es www.fibanc.es *sanostra.es www.inversis.com oie. 
cajamadridempresas.es 


vs*.absa.co.za mijn.postbank.nl 


Marsco.com vmd.ca Citrix scottrade.com streetscape. 
com principal.com thinkorswim.com sharebuilder.com 
fs.ml.com netxselect.com netxclient.com 


accu.com.au adelaidebank.com.au amp.com.au bigsky. 
net.au boq.com.au commbank.com.au communityfirst.com. 
au cu.com.au cua.com.au imb.com.au inetbank.net.au 


mecu.com.au nab.com.au suncorp.com.au westpac.com.au 
hsbc.com.au bankwest.com.au bendigobank.com.au necu. 
com.au comsec.com.au ebanking.pcu.com.au 


teacherscreditunion.com.au policecredit.com.au/ 
easyaccess stgeorge.com.au banksa.com.au humebuild. 


com.au zecco.com etrade tradingdirect.com ameriprise. 


com 


businesscreditcardsonline.co.uk alpha.gr 
bankofcyprus.gr marfinegnatiabank.gr winbank.gr 
eurobank.gr nbg.gr millenniumbank.gr piraeusbank.com 
emporiki.gr 


centralbank.gov.cy bankofcyprus.com laiki.com usb. 
com.cy hellenic coopbank.com.cy universalbank.com.cy 


anbusiness.com paypal.com hellenicbank 
citibankonline.ca clkccm cashplus capitalonebank.com 
nationalcity.com webcashmanager cashman towernet 


web-access.com cashproweb.com bankonline.sboff. 

com constantcontact.com/login.jsp dotmailer.co.uk/ 
login.aspx yourmailinglistprovider.com/controlpanel 
r57shell.php c99shell webadmi 


tee 
And the heavily ciphered rootkit configurations files: 


Cea) 

INST 

gco00 

services.exe 

!This program cannot be run in DOS mode. 
Crain) 

0$0/050; 0D0J0QOWO*0d0i0 

gs00 


!winlogon.exe;services.exe;csrss.exe; spoolsv.exe; 


lsass.exe;smss.exe;system.exe 
!This program cannot be run in DOS mode. 


(s32) 


We were therefore able to verify that the taint propagation 
on the hard drive reflects the MBR contamination and also 
the contamination of the following sectors containing the 
rootkit itself. 


The previous check was only done in order to validate 

the tainting at the hard disk level in the presence of an 
MBR-infecting virus. The original version of Mebroot 

[1] uses sectors 60/61/62 to store its boot loader and the 
original boot sector, but contrary to our expectations, these 
sectors were not tainted. Indeed, after a quick analysis, the 
new variant sample (d438c3cb7ab994333fe496ef04£734d0) 
had partially changed its modus operandi — its boot loader 
and the original boot sector were now placed at the end of 
the hard disk. This new variant is immune to any detection/ 
disinfection using the anti-rootkit gmer (and mbr.exe [2]). 
This is probably also the case for many of today’s anti-virus 
solutions. 


2.2 Further results 


Similar sets of results for the PRG/Zeus/NTOS, Infostealer, 
Ambler, Banker and PWS-OnlineGames.cz families can be 
found at http://www.virusbtn.com/vba/2010/02/vb201002- 

data-tainting-results. 


CONCLUSION 


In this paper we have revisited many concepts of the old 
binary instrumentation domain. In the early 90s DEC 
applied this kind of technology to translate VAX binary 
images to alpha platforms; in the 70s IBM applied it to 
provide debugging. 


Nowadays, superior hardware performance allows 
virtualization and binary analysis to be used in new ways. 
We have shown here one such application, which is usable 
on real-life malicious software. In the future we plan 

to improve our implementation by adding static binary 
analysis and constraint solving capabilities. 
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INTRODUCTION TO ADVANCED 
MEMORY ANALYSIS 


Ken Dunham 
iSIGHT Partners, USA 


Cybercriminals are pushing fraud to the limits, now resorting 
to memory-only tactics to subvert the Windows operating 
system for financial gain. These recent tactics pose a 
challenge for traditional forensics, law enforcement, auditing 
and incident response procedures, and require new ways of 
dealing with affected systems. Advanced memory analysis 
allows for rapid assessment of potentially hostile executables 
in memory. There are three distinct phases of operation: 
analysis of a live system (triage), dumping of volatile data to 
a file (capture), and analysis of combined data (analysis). 


TRIAGE 


Incident handlers often locate infected computers through 
egress traffic via IDS/IPS-type solutions. Once a computer 
is known to be sending suspect or known hostile traffic, 

the hunt begins to find the offending process, image files, 
and scope of compromise. While some malicious programs 
hide data in Alternate Data Streams (ADS) and other tricky 
places, a movement towards kernel-level rootkit subversion 
and RAM-only code is underway in the wild. As a result, 
incident handlers who are not equipped with advanced 
stealth code identification tools and techniques are unable 
to triage a system properly to identify potential kernel-level 
rootkits on an infected host. 


Triage begins with the age-old basics of incident handling 
and forensic techniques. Ideally, policy enables the incident 
handler to collect information relating to volatile data on the 
system. If policy only allows a hard-core traditional forensic 
approach, critical volatile RAM-only data will be lost. 

To focus on memory analysis and volatile data, incident 
handlers must begin triage with operations such as the 
following, which are largely focused on malicious process 
and image identification: 


1. Windows Task Explorer (CTRL-ALT-DELETE) 


a. Ifthe Task Explorer won’t open, this is a sign that 
malicious code may be hindering the use of security 
tools on the system. 


b. Once the Task Explorer is open, look for anything 
in the list of processes that shouldn’t be there. 
While it is increasingly rare, malicious programs do 
sometimes still reveal themselves in Windows Task 
Explorer. Even when something is visible in memory, 
other components of an attack may be hidden. 
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c. Also look for anything that is missing from the list 
of processes. For example, one variant of Haxdoor 
injects explorer.exe and then hides the process 
it injects. Explorer.exe should always be visible 
within Windows Task Explorer; if it isn’t, a rootkit is 
probably hiding it. 






~)DPCs 
7) System 
© PYjsmss.exe 


Deferred Procedur.. 







Windows NT Ses... Microsoft ... 
Prjcstss.exe Client Server Runt... Microsoft 


© @ winlogon.exe eB) 






Eel) 


Windows Task Manager 
thil File Options Yiew Shut Down Help 









—_—_— 
Applications | Processes | Performance | Networking | Users 











Image Name User Name CPU Mem Usac 

| alg.exe LOCAL SERVICE 00 3,416 

| csrss.exe ‘SYSTEM oo 3,524 
GoogleToolbarNotifier.exe Owner 2 

| sass.exe 
procexp.exe 

services.exe 






Figure 1: Explorer.exe is hidden by a rootkit and isn’t 
visible when it should be. 


2. Process Explorer (http://technet.microsoft.com/ 
en-us/sysinternals/bb896653.aspx) 


Following the same procedures as when working with 
Windows Task Manager, look for extra and/or missing 
processes such as explorer.exe, csrss.exe and Isass.exe. 
Although it is increasingly unlikely that any rootkit 
processes will be found using this method, it is worthy of 
investigation since some malicious programs are visible 
using this tool but not with Windows Task Manager, 
indicating a possible rootkit process. 


3. F-Port (http://www.foundstone.com/us/ 
resources/proddesc/fport.htm) 


Run F-Port and dump the results to a file. It is a good 

idea to have a baseline dump from a known clean system 

to compare against the dump from the possibly infected 
system. This enables the incident handler to identify what 
F-Port has seen in memory mapped to specific ports and file 
images at the time of analysis, and to quickly identify what 
might be malicious. 


Looking at the dumps shown in Figure 2, can you identify 
which one is from an infected system? Column B is longer 
for a reason: several new processes have been spawned by 
explorer.exe. This suggests an injected malicious process 
attempting to communicate with a remote C&C server. 


By performing a standard ‘diff’ or difference analysis 
(common in the forensics field), an incident handler can very 
quickly identify potentially hostile processes. To do this even 





more quickly, consider using the FCompare utility 
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1760 GoogleToolbarNotifier-> 1025 TCP C:\Program 


exe 
1176 -> 1029 TCP 
0 System => 123 UDP 
0 System -> 137 UDP 
0 System “> 13 UDP 
976 -> 445 UDP 
4 System -> 500 UDP 





1760 GoogleToolbarNotifier-> 1900 UDP C:\Program 


exe 
0 System -> 1900 UDP 
1176 -> 4500 UDP 





Files\Google\GoogleToolbarNotifier\GoogleToolbarNotifier . 


Files\Google\GoogleToolbarNotifier\GoogleToolbarNotifier . 





Dump A Dump B 

Pid Process Port Proto Path Pid Process Port Proto Path 
976 => 135 TCP 976 3S > 135. TCP 

4 System “3 139 TCP 4 System => 139 TCP 

4 System -> 445 TCP 4 System -> 445 TCP 


760 GoogleToolbarNotifier-> 1025 TCP c:\Program 
Files\Google\GoogleToolbarNotifier\GoogleToolbarNotifier. 
exe 























1176 =5:) 1029 “PEP 

1552 Explorer -> 16016 TCP C:\WINDOWS\ 
Explorer. EXE 

1552 Explorer -> 16661 TCP C:\WINDOWS\ 
Explorer .EXE 

1552 Explorer -> 28285 TCP C:\WINDOWS\ 
Explorer .EXE 

1552 Explorer 25 -3'853:0) "PEP C:\WINDOWS\ 
Explorer .EXE 

552 Explorer => 123 UDP C:\WINDOWS\ 
Explorer .EXE 

176 => 137 UDP 

4 System -> 138 UDP 

976 -> 445 UDP 

4 System -> 500 UDP 

1552 Explorer -> 1900 UDP C:\WINDOWS\ 


Explorer. EXE 

1760 GoogleToolbarNotifier-> 1900 UDP c:\Program 
Files\Google\GoogleToolbarNot ifier\GoogleToolbarNotifier . 
exe 

1552 Explorer -> 4500 UDP 
Explorer. EXE 


C: \WINDOWS\ 





Figure 2: Baseline dumps from a clean system and from a possibly infected system. 


(http://www.oneysoft.com/fcompare.htm), which highlights 
changes between dump files of this nature using the File: 

Compare option. While not perfect, this can be useful for rapid 
triage of larger dump files compared against baseline dumps. 


In Figure 3, FCompare highlights the changes between two 
F-Port dumps, showing potentially malicious processes in 
yellow on the right. 


4. TCPView (http://technet.microsoft.com/ 
en-us/sysinternals/bb897437.aspx) 


TCP View is a great tool for a quick visual overview 

of any running processes that are responsible for TCP 
communications. Since many trojans and other malicious 
codes attempt to communicate with remote C&Cs via TCP, 
this is a great way to identify potentially hostile activities. 
In the example shown in Figure 4, notice that several 

ports related to the ‘non-existent’ process as identified by 
TCPView, are all in the listening state. 





File Compare - 
File Edit View Help 








Port v2.0 — TCP/IP Process to Port Mapper 
Copyright 2000 by Foundstone, Inc 
Ihnttp:“/www, foundstone.con 


(Copyright 2000 by Foundstone. Inc 
Inttp://www. foundstone.com 


Process Proto Path Process Port Proto Path 
TCP -> 135 TCP 
System TCE System -> 139 TCP 
System TCE Systen -> 445 TCP 
GoogleToolbarNotifier-> 1025 TCP C:M GoogleToolbarNotifier-> 1025 TCP 
-> 1029 TCP -> 1029 TCP 








FPort v2.0 — TCP/IP Process to Port Mapper 





[Soo0001 Mooooo1 | 


Figure 3: Potentially malicious processes are highlighted in yellow. 





TCPView - Sysinternals: www.sysinternals.com 


File Options Process View Help 
Ma <2 


Process 


1 Isass.exe:724 

[1 Isass.exe:724 

1 svchost.exe:1072 
£1 svchost.exe:1072 
£1 svchost.exe:1196 
5 svchost.exe:1196 
—) System:4 


f (e\ 


Local Address 
Goatisakmp 
Goat:4500 
Goatntp 
goat:ntp 
Goat1900 
goat:1900 ig 


—) System:4 ‘ e oe 

—) System:4 i 
GoogleT oolbarNotifier.exe:1760 
<non-existent>:1552 


goat:1025 


: 74.125.127.103:http ESTA 
Goat: 16016 Goat usT 
Goat:16661 


<non-existent>:1552 TcP Goat:38530 Goat0 LISTE 
5 alg.exe:1176 TcP Goat:1029 Goat:0 LISTE! 
2) svchost. exe:976 TEP: Goatepmap Goat:0 LUSTE! 
System:4 Tce Goatmicrosoft-ds  Goat:0 LISTE! 
J System:4 TCP goatnetbios-ssn  Goat:0 LISTE! 





Figure 4: TCPView shows that several ports related to the 
‘non-existent’ process are in the listening state. 


TCP View reveals several new ‘non-existent’ TCP processes 
related to the Haxdoor rootkit. 


5. lceSword (http://www.brothersoft.com/ 
icesword-63677.html) 


IceSword highlights any data it believes to be associated 
with rootkit activity. This can be a great visual when it 
works properly, as in the example shown in Figure 5 where 
Haxdoor has injected explorer.exe. 


In the example of Haxdoor, JceSword is able to show rootkit 
components in many areas, including but not limited to a 
hostile process highlighted in red, new processes listening 


i A539 


ageName 1D 
1c} EAsystem id... 0 NTOSKernel 
Process Poisystem 4 NTOSKernel 
= Bvrwereser... 196 C:\Program Files\VMware\vMware Tools\VMwareService.exe 
J Dlsmss.exe 564 C:\WINDOWSIsystem32\smss.exe 
: Clesrss.exe 644 C:\WINDOWS\system32\csrss.exe 
Pott BB wirkogon.exe 668 C:\WINDOWS\system32\winlogon.exe 
Eiservices.exe 712 C:AWINDOWS\system32\services.exe 
=| isass.exe 724 C:\WINDOWS\|system32\Isass.exe 
Kemel Module A Tepview.exe 864 C:\Documents and Settings\Owner\Desktop\Tcpview.exe 
ivmacthip.exe 880 C:\Program Files\VMwarelvMware Tools|vmacthip.exe 
Xisvchost.exe 904 C:\WINDOWS|system32\svchost.exe 
ey svchost.exe 976 C:\WINDOWS\system32\svchost.exe 
Startup “IceSword.exe 1028 C:\Documents and Settings\Owner\My Documents\Anti-ro0.... 
svchost.exe 1072 C:\WINDOWS|system32\svchost.exe 
{= CUsvchost.exe 1136 C:\WINDOWS\system32\svchost.exe 
Plag.exe 1176 C:\WINDOWS\system32\alg.exe 
Win32 Services svchost.exe 1196 C:\WINDOWS|system32\svchost.exe 
lwscritfy.exe 1404 C:\WINDOWS\|system32\wscntfy.exe 
A Cspoolsy.exe 1532 C:\WINDOWS\system32\spoolsv.exe 
Q explorer.exe 1552 C:\WINDOWS\explorer.exe 
SPI Btastmgr.exe 1600 C:AWINDOWS\system32\taskmor.exe 
: owuauclt.exe 1712 C:\WINDOWS|system32\wuauck.exe 
id vMwareTra... 1716 C:\Program Files\VMware|VMware Tools\¥MwareTray.exe 
BHO ViMwareUs... 1724 C:\Program Files\vMware\vMware Tools\vMwareUser.exe 
}GoogleTool... 1760 C:\Program Files\Google|Google ToolbarNotifier|\GoogleTool. .. 


Figure 5: IceSword highlights a malicious rootkit process injected into explorer.exe. 
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(not in red), system service descriptor table (SSDT) 
hooks, log/thread creation activity, and hidden files in the 
Windows System32 directory. Analysis of other areas, 
such as the Windows registry, are also possible using this 
powerful tool. 


Comparing a Windows file listing of the System32 directory 
against an JceSword file listing of the same directory can 
also reveal hidden files, as shown in Figure 6. Common 
locations for concealing malcode are in the System32, 
Windows, and various related directories. 


Hint: A good way to compare directories is to sort by 
created date. Simply right-click on the headers for file 
listings and select ‘Date Created’ and then click on the tab 
after creation to sort in the order desired. 


CAPTURE 


With triage completed, there may be clues that a rootkit is 
running on the system. In some cases an incident handler 
will already have captured hostile image files using tools like 
IceSword and/or forensic techniques. If further investigation 
is required, capturing physical memory to a file is the next 
step. Image files are then analysed using the Volatility 
Framework and/or advanced reverse engineering techniques. 


Several utilities exist to image physical memory (dump 
volatile data to a file). Raw image files of physical memory 
are DD-style copies of the memory but do not contain 
processor state. This enables an incident handler to compare 
what is found inside a dump file to what was found at the 
triage stage. Additionally, processes in memory — including 
hidden hostile executables — can 
be extracted from an image file for 
analysis. 


Several tools exist to quickly 
dump physical memory to an 
image file. Dumps typically take 


Ox80S52A20 Ready _ 
Ox623C87C0 Ready 240k 


Oxe1FCIZAD Ready 4324 several minutes and can be quite 
eienaes, Reed Pes large: on average 3GB to 4GB and 
Ox61F287F0 Ready 1168k : 

OxBiF3FDAD Ready 2100 upwards. It is common to dump 
Baia? tao pee to the C: drive in order to locate 
Peetieanl ised a and extract images and other data 
=f eck. 

OxS1EB5020 Ready 19376k 

Ox8224A480 Ready WS2k = 

OxB20ESAF8 Ready 416k 1. Win32dd 

0x822A90A0 Ready 4248k . E 

oxezznBe2e Ide 1912k (http://windd.msuiche.net/) 
0x822390A0 Idle $240k 

Daler feck Bri Win32dd is a free tool that can be 
Reis) (nee pea used to dump physical memory to 
sen cod Fes a file. It supports Windows 2000 


to Windows 7 and is capable of 
producing a full snapshot similar 
to a Microsoft crash dump file. 
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" CAUNDOWSIRtn32 : a 3. Memoryze (http://www.mandiant.com/ 
H Oe © - | Dewar eer | EE software/memoryze.htm) 
Address |G CAWInDOWS|systemaz 
wane Foose ae z cee ‘om Memoryze is a powerful tool, but it requires a set-up 
ao SRM 18 takdintienin Wisi installer to be run before it can be used — this is not usually 
SS EE possible in an incident management situation. Furthermore, 
faXee®. : — the output is best analysed using other Mandiant tools 
L seme saaeine = that have similar set-up requirements and customized 
oa : a interpretations. This tool is more useful for in-depth 
= gun a investigations or in environments where such tools are used 
a : — aoe 2 across the enterprise rather than individually for incident 
SBE SE | handing 
wa cist snes anata aioe If Memoryze is to be installed and used, a directory must 
ane SS fees see be created for dump data. Once such a directory has been 
pad 2 oe created, the tool is able to dump memory using a batch file 
oa fe ee as shown below: 
saa s Seamer | ee er ee er erie 








Located at C:\Program Files\Mandiant \Memoryze\ 
MemoryDD.bat\ in most situations. 





Mandiant has another tool called Audit Viewer which is 
useful for analysing Memoryze images and XML data. A 
specific Python solution is required to fully install and use 
the software. 


Figure 6: Files appear within IceSword that are not visible 
within Windows itself, revealing a rootkit running on 
the system. 


Win32dd is a very intuitive, easy-to-use tool that does a 


great job of imaging quickly. When running it in a CMD 4. VMEM (VMware) 

window it is wise to navigate to the directory containing the VMware is commonly used to test malicious codes and to 

executable to avoid the errors that might appear if the SYS research emergent threats. If code runs inside VMware, 

file can’t be located (e.g. “cannot start the driver’). or a virtualized desktop is in use, analysis of a .vmem file 
win32dd -r C:\filename.dmp is another option for determining what is in memory on a 
-r = raw memory dump/snapshot suspect host. Simply click on the VMware ‘suspend’ button 

to create a ‘.vmem/’ file on the host system. Use this image 
2. MDD (http://sourceforge.net/projects/mdd/) file for advanced memory analysis. 





MDD is another tool that can be used to dump physical 
memory to a file. It is open source, hosted by SourceForge. It 
supports Windows 2000, XP, Vista and Windows Server. This 
program was not very stable in the limited tests I performed, 
but it did the job well when crashes did not occur. 






File Edit View YM Team 


fH) >jf& BOQ 
eBaslill Suspend This Virtual Machine } 







mdd -v -o C:\filename.dmp 


-v = verbose; -o = output file followed by path/name : . : 
Figure 8: Suspending VMware operating systems creates a 


.vmem file on the host system. 


s and Settings\Administrator\Desktop\mdd_1. vy -o C:\dump2 


5. Defldd (http://dcfidd. 
ManTech Physical Memory Dump Utility ne sourceforge.net/) 


right (C> 2008 ManTech Security & Mission urance 


ith ABSOLUTELY NO WARRANTY; for details use option ‘-w’ Defidd is yet another method of creating 
st 2 it - 


, and you are welcome to 


in condit ions} use option ‘-c for « i an image file The syntax can be a 
Dumping 511.48 MB of physical memory to file ’C:\dump2.dmp’. bit tricky with forward and backslash 
conventions: 





dcfldd if=/dev/mem of=c: \filename.dmp 
Figure 7: Dumping physical memory to an image file using MDD. conv=sync,noerror 





Volatility Framework Installation 


Applications:Terminal 


su - 
Superuser mode 


CD /home/CurrentUser/desktop 


Navigate to the Desktop 


wget https://www.volatilesystems.com/volatility/1.3/ 
Volatility-1.3_Beta.tar.gz 
Download a copy of the VF. 


Right-click on the .gz file and select ‘Extract Here’ 
Extracts the archive. 





ANALYSIS 


Once physical memory has been captured to an image file 
you have a huge file with a bunch of data within it waiting 
to be discovered. Incident handlers should now have a very 
good idea of what might be malicious, or where to look on 
a system. The goal now is to use the Volatility Framework 
to extract executables of interest in memory and to compare 
the image file against earlier triage data in a diff analysis. 


Volatility Framework 
(https://www.volatilesystems.com/default/ 
volatility#overview) 


I prefer to use a Ubuntu build to install the Volatility 
Framework. Install details are shown in the callout box 
above. Common installation pitfalls include not entering into 
SU mode (which is required for installation); downloading 
to the root directory and wondering where the download 

is when done (see CD in step 3 to mitigate); and not using 
Terminal properly to run the Python Volatility file. 


Once installation is complete, Volatility Framework 
commands can be run against the image files copied into 
the analysis system. Open the terminal and navigate to the 
Volatility Framework directory on the desktop. Then enter 
the following command to view options for the tool: 


python volatility --help 
A sample dump of the options provided by the Volatility 
Framework are below. Items in bold are of greatest interest 
to an incident handler attempting to compare triage data 


against what is found in the physical memory image file 
and/or capture of hostile hidden binaries on the system. 


usage: volatility cmd [cmd_opts] 
Run command cmd with options cmd_opts 


For help on a specific command, run ‘volatility cmd -- 
help’ 
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Supported internal commands: 


connections 
connscan 
connscan2 
datetime 
dlllist 
dmp2raw 
dmpchk 

files 
hibinfo 
ident 


memdmp 


memmap 
modscan 
modscan2 
modules 
procdump 
pslist 
psscan 
psscan2 
raw2dmp 
regobjkeys 
sockets 
sockscan 
sockscan2 


strings 


thrdscan 
thrdscan2 
vaddump 
vadinfo 


vadwalk 


Print list of open connections 

Scan for connection objects 

Scan for connection objects (New) 

Get date/time information for image 

Print list of loaded dlls for each process 
Convert a crash dump to a raw dump 
Dump crash dump information 

Print list of open files for each process 
Convert hibernation file to linear raw image 
Identify image properties 


Dump the addressable memory for a 
process 


Print the memory map 

Scan for modules 

Scan for module objects (New) 

Print list of loaded modules 

Dump a process to an executable sample 
Print list of running processes 

Scan for EPROCESS objects 

Scan for process objects (New) 

Convert a raw dump to a crash dump 
Print list of open regkeys for each process 
Print list of open sockets 

Scan for socket objects 

Scan for socket objects (New) 


Match physical offsets to virtual 
addresses (may take a while, VERY 
verbose) 


Scan for ETHREAD objects 
Scan for thread objects (New) 
Dump the vad sections to files 
Dump the vad info 

Walk the vad tree 


Supported plug-in commands: 


memmap_ex 2 
pslist_ex_ 1 
pslist_ex 3 


usrdmp_ex_2 


Print the memory map 
Print list running processes 
Print list running processes 


Dump the address space for a process 
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Example: volatility pslist -£ /path/to/my/ | wame Pid PPid Thds Hnds Time 
ee System 4 0 55 280 Thu Jan 01 00:00:00 1970 
To get specific parameters and help on smss.exe 420 4 3 19 Wed Mar 25 17:32:22 2009 
commands of interest, use the syntax ‘python 
we , csrss.exe 692 420 3 348 Wed Mar 25 17:32:30 2009 
volatility command --help’. For example, 
‘python volatility pslist --help’ produces the winlogon.exe 716 420 9 516 Wed Mar 25 17:32:31 2009 
following list of options for the pslist command: | services.exe 760 716 5 248 Wed Mar 25 17:32:32 2009 
Usage: pslist [options] (see --help) lsass.exe 772 716 22 342 Wed Mar 25 17:32:33 2009 
Options: vmacthlp.exe 936 760 25 Wed Mar 25 17:32:33 2009 
eg ene Tp eHow Ease help messsge audvexte svchost .exe 952 760 6 95 Wed Mar 25 17:32:34 2009 
-f FILENAME, --file=FILENAME (required) XP 
5 svchost.exe 1016 760 1 250 Wed Mar 25 17:32:34 2009 
SP2 Image file 
-b BASE, --base=BASE (optional, otherwise svchost.exe 1100 760 57 292 Wed Mar 25 17:32:34 2009 
best guess is made) physical offset (in 
: svchost.exe 1176 760 5 76 Wed Mar 25 17:32:34 2009 
hex) of directory table base 
-t TYPE, --type=TYPE (optional svchost.exe 1316 760 13 93 Wed Mar 25 17:32:35 2009 
detaulb=tautot) sdentigy. the mage: type spoolsv.exe 1460 760 11 16 Wed Mar 25 17:32:36 2009 
(pae, nopae, auto) 
. : et explorer.exe 1680 1632 27 685 Wed Mar 25 17:32:37 2009 
When running the command ‘python volatility 
pslist _f dump.dmp’, where dump.dmp is the VMwareTray.exe 212 1680 1 29 Wed Mar 25 17:32:40 2009 
file containing physical memory, the Volatility VMwareUser .exe 224 1680 8 115 Wed Mar 25 17:32:40 2009 
Framework provides the sample output shown msmsgs.exe 244 1680 2 155 Wed Mar 25 17:32:41 2009 
in Figure 9. 
VMwareService.e 668 760 3 147 Wed Mar 25 17:32:43 2009 
The list in Figure 9 clearly shows Win32dd, alg.exe 2008 760 5 103. Wed Mar 25 17:32:50 2009 
FPort and other processes in memory along 
: ; . F tfy. 308 1100 1 28 Wed Mar 25 17:32:50 2009 
with their process IDs. Comparing this Meet ge reas 
against triage data and correlating PIDs is the procexp.exe 1188 1680 0 = Fri Oct 09 20:18:43 2009 
first step in performing advanced memory aports.exe 660 1680 0 = Fri Oct 09 20:18:50 2009 
analysis diff comparisons to discover hidden . 
. eae jj verclsid.exe 240 1680 0 os Fri Oct 09 20:18:56 2009 
processes. Once a hostile process is identified, 
the Volatility Framework can be used to dump verclsid.exe 1692 1680 0 = Fri Oct 09 20:18:56 2009 
it to an executable file for further analysis. In cmd.exe 740 1680 0 7 Fri Oct 09 20:18:57 2009 
the example statement below, a hostile process Fport .exe 1072 740 0 : Fri Oct 09 20:19:31 2009 
with the PID value of 1004 is dumped to an ; : 
f verclsid.exe 976 1680 0O - Fri Oct 09 20:20:04 2009 
executable file for further analysis: 
verclsid.exe 1860 1680 0 - Fri Oct 09 20:20:04 2009 
python volatility procdump -f dump.dmp -p 
1004 cmd.exe 1640 1680 0 = Fri Oct 09 20:29:35 2009 
NOTE: If you don’t specify the PID value, all cmd.exe 2004 1680 2 A7 Fri Oct 09 20:29:41 2009 
processes will be dumped to executable files. win32dd.exe 1480 2004 2 44 Fri Oct 09 20:29:56 2009 











Extracted binaries enable researchers to scan 
files to see if they are infected by malicious 
code, perform reverse engineering, and more. 


Figure 9: Sample output provided by the Volatility Framework. 


Investigations should start with a strings anti-rootkit and forensic techniques can now be used 
analysis. Most processes are not obfuscated or packed to identify and extract specific image files of interest. 

while in memory, thus allowing plenty of opportunities Additionally, advanced analysis of extracted raw image data 
for strings analysis. In some cases URLs and other data frequently leads to discoveries that can impact live system 
can easily be seen when looking at strings of executables analysis and reverse engineering, URLs, remote server 
captured from a dump file. investigations and related abuse data, and more. 

Additional work can now be done both on the original In next month’s issue, we will take a detailed look at the 
infected system and in the analysis of memory data and use of advanced memory analysis on a system infected 
extracted executables. Going back to the original system, with Haxdoor. 





COMPARATIVE REVIEW 


NOVELL SUSE LINUX 
ENTERPRISE SERVER 11 


John Hawes 


Our annual excursion to the calm and balmy shores of 
Linux comes at the perfect time for us. The stresses and 
strains of the previous comparative — featuring a record 
number of participants on the shiny new Windows 7 
platform — are gradually fading to a glorious, if rather 
painful memory, while the prospect looms of the XP 
comparative in the spring, which promises an even larger 
field of products to slog through. Sandwiched between 
these two behemoths, the Linux test provides a welcome 
moment of respite. 


With far fewer products available for the Linux platform 
than for most others we test on, we always expect a quiet 
month, but it appeared from the start that our choice of 
distribution would make for an even smaller test than 
anticipated. Although Novell’s SUSE Linux is one of the 
most well funded and heavily marketed commercial server 
distributions, and its most recent edition (version 11) was 
released some nine months prior to the test deadline, it still 
presented enough of a challenge to put off entries from 
several of those normally expected to take part in our tests. 
The two largest security firms, Symantec and McAfee, 
were unable to provide products supporting the platform, 
although Symantec promises a new edition with full support 
due for release very soon. 


Several others also decided not to take part due to timing 
issues and new releases pending. 


Another major vendor also opted to skip this test, again 
with a significant upgrade to its Linux product close on the 
horizon but not quite ready for testing. This decision marks 
something of the end of an era: VB has been running VB 100 
comparative reviews since January 1998, more or less every 
two months, with a total of 67 sets of results published so 
far — this month’s test will be the first time that Kaspersky 
Lab has not submitted a product. A sad day indeed. 


However, some nine products did make their way to us 

in time for the test deadline, with most of the remaining 
regular participants present and no further surprises. Small 
numbers do not necessarily make for a simple test of course, 
and previous experience of Linux tests has led us to expect 
all manner of opaque and confusing installation procedures, 
unusual and esoteric implementation and incomplete, 
inadequate and even well-hidden documentation. Hoping 
for a smooth and simple test (but as always prepared for the 
worst), we settled ourselves into the test lab for what was 
guaranteed to be an interesting month. 


VIRUS BULLETIN 


PLATFORM AND TEST SETS 


Novell’s acquisition of the SUSE distribution, announced 
in 2003 and finalized in early 2004, brought SUSE to the 
highest level of commercially supported Linux flavours. 
Always among the market leaders in Europe, it now 
stands as one of few likely challengers for Red Hat in the 
business sector. Successive releases have brought ever 
greater stability, completeness of vision and ease of use. 
The slick installer and the advanced Yast configuration 
tool bring most tasks involved in setting up and running 

a system, desktop or server within the grasp of even the 
most modest administrator. The platform has long been a 
favourite in the VB lab, with the fully open source variant 
OpenSUSE running on many of the servers that support 
our test networks. The more sober server edition is also 
the platform of choice for our anti-spam test network, 

and is selected by default if solution providers have no 
preference. So the task of preparing the test systems was a 
straightforward one. Installing and cloning systems was a 
fast and easy process, and few adjustments were required 
beyond pointing a few network shares to the right places 
and sharing the storage areas for the test sets ready for on- 
access testing. A client system, running Windows XP SP3, 
was set up with these shares mounted as network drives, 
with the standard set of scripts to run the on-access tests, 
and things were ready to go. 


Putting the test sets in place proved similarly free from 
problems. The latest additions to the WildList were 
reasonably unremarkable, with yet more Koobface and 
OnlineGames variants continuing to dominate the list, and 
the old guard — the reams of Netsky and Mytob variants 
which once held sway over the list — continuing to decline. 
The most significant items on the list remain the complex 
W32/Virut strains, of which yet another new variant was 
added in recent months; as usual, our automated replicator 
churned out several thousand examples ready to challenge 
the products’ detection abilities to the utmost. 


Elsewhere in the test sets everything was much as normal. 
The trojan set was slightly larger than usual thanks to a 
longer than average gap since the last test and some further 
expansion of our sample-gathering efforts. Meanwhile, the 
RAP sets were kept to a reasonable size thanks to a notable 
decrease in the number of incoming samples over the 
Christmas and New Year period, when most of the samples 
were taken in (probably due to various labs taking time off 
over the festive season); numbers quickly climbed back to 
previous levels a few weeks into 2010, with many sources 
providing extra large bundles to catch up with backlogs. 


The speed sets were left largely unchanged, other than a 
little cleaning of inappropriate files which had slipped in, 
and the clean set had a fairly average number of additions, 
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most of which were popular freeware utilities and some 
software provided free with magazines and hardware 
acquired by the lab in recent months. A dedicated set of 
Linux files was also compiled for the speed tests, taken 
from the /bin, /sbin, /etc, /opt and /usr folders of one of the 
test machines. As usual for the speed tests, scanning speeds 
using both default settings and ‘full’ settings were recorded 
— where necessary, settings were increased to include all file 
types with no size limit, scanning archives internally to the 
highest available depth. A product’s times were counted in 
the full column if files with non-standard extensions were 
detected and, for the archive set, if at least four of the eight 
archive types checked were scanned to a depth of at least 
four levels. Thanks to the fair number of compressed files in 
the Linux speed set, this was treated in the same way as the 
archive set for this month’s test. 


With everything set up and more or less in order, we got 
down to business. 


Alwil avast! for Linux 3.2.0_rc 


Itw 100.00% Polymorphic 99.39% 
ItW (o/a) 100.00% Trojans 92.60% 
Worms & bots 100.00% False positives 0 


® 


Alwil’s product 
was provided 

as a Selection of 
RPM installer 
files, along with 
some instructions 
on compiling 

and installing the 
Dazuko filtering 
module required by the on-access scanner. Several 
steps were required, but thanks to the clear instructions 
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everything ran through smoothly and we were soon 
underway with our first run through the tests. 


Running of scans from the command line and operation of 
the on-access guard proved logical and simple, following 
pretty simple and predictable formats, and with decent 
speeds across all sets, results were gathered in pleasingly 
short order. Detection rates were as excellent as ever, with 
scanning speeds even more impressive in both modes. No 
problems were encountered in the WildList or any of the 
clean sets, and Alwil is duly awarded another VB 100 for its 
collection. 


Avira AntiVir Linux Server Professional 3.0.5 


Itw 100.00% Polymorphic 100.00% 
ItW (o/a) 100.00% Trojans 98.32% 
Worms & bots 100.00% _ False positives 0 


Avira’s Linux 
solution uses 

the Dazuko filter 
module in a slightly 
different fashion, 
but provides it 
pre-compiled and 
ready to go with 
just a minor tweak 
required to one of the set-up scripts. Installation is well 
automated and lucid, and documentation is similarly clear. 
Operation and control of the product is thus straightforward, 
and with good speeds throughout, testing once again took 
little time or effort. 
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RAP 85.3% 


Some truly superb detection figures were achieved, nearing 
perfection in the trojans set and pretty impressive in the 
RAP sets. With the WildList and clean sets causing no 
difficulties, Avira also comfortably earns another VB 100. 
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CA Threat Manager 8.1.5379.0 


Itw 100.00% Polymorphic 92.00% 
ItW (o/a) 100.00% Trojans 47.52% 
Worms & bots 100.00% False positives 0 


CA’s product has 

a rather more 
involved and 
complex set-up 
procedure, but 
ample instructions 
were provided and 
the product was up 
and running without 
much ado. A GUI is provided, accessible from a built-in 
web server, which closely resembles that seen in numerous 
Windows tests over the last few years. This proved to 

offer all the functions required, but not in great depth and 
without the finer control provided by command-line and 
configuration file set-ups — the preferred method of more 
serious Linux admins, particularly at the server level. A 
command-line tool for on-demand scanning is provided, but 
seemed unwilling to work for us without deeper research, 
so we mostly made do with the GUI. This proved a rather 
frustrating path, as the interface was flaky in the extreme, 
with around one click in five (and sometimes as many as 
one in three) producing a page error and requiring a refresh 
of the browser and a retry at configuring. Nevertheless, we 
got there in the end, with the only lasting problem being 

an apparent lack of archive scanning on access despite 
options to enable it in the interface — a problem we have 
noted many times previously with the Windows version of 
the same product. 
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RAP 32.2% 


Speeds were as excellent as we have come to expect from 
CA’s remarkably quick engine, and while detection rates 





in the trojans and RAP sets were rather disappointing, no 
problems were encountered in the WildList set and no false 
positives turned up in the clean sets, thus qualifying CA for 
a VB100 award. 


eScan for Linux File Servers 3.3.-3.sles11 


Itw 100.00% Polymorphic 100.00% 
ItW (o/a) 99.48% Trojans 92.24% 
Worms & bots 100.00% False positives 0 


The Linux version of eScan is 
another complete and professional 
server package, again with a 
web-accessible GUI as well as 

a desktop interface for running 
on-demand scans, but where 
possible we went with the command 
line to enable better automation 

of tasks. Installation was fairly 
painless, with a set of RPM installers to run and the on- 
access protection provided on Samba shares with some small 
additions to make to the Samba configuration file. All of this 
is clearly documented in an accompanying PDF manual. 


RAP 75.9% 


Scanning speeds were not the fastest, partly thanks to some 
very thorough default settings, but detection rates seemed 
generally good. However, on checking the results we 
found a number of unexpected misses in the WildList and 
worms and bots sets, with files not spotted on access but 
easily noted on demand. Deeper analysis showed that the 
on-access scanner is set to ignore files larger than 2048KB 
by default — presumably to mitigate slowdowns caused by 
the thorough scanning. Retrying the speed tests with the 
limit disabled resulted in numerous problems, including 
the scanning engine daemon shutting down and disabling 
all access to the Samba share. Since several samples in 
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the WildList — including a nasty W32/Bagle worm — were ESET also offers ° 
larger than 2MB and thus ignored in the default setting, some nice simple a 
eScan is denied a VB100 award this month. install scripts — not f 
as straightforward 
ESET Security for Linux 3.0.15 as some, but still 
fairly easy to 
tw 100.00% Polymorphic 100.00% operate. On-access RAP 83 hy 
. scanning can be iL 
ItW (0/a) 100.00% Trojans 96.81% : ‘ 
provided either 
Worms & bots 100.00% False positives 0 using the Dazuko module, allowing full system protection, 
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Alwil avast! Avira AntiVir CAThreat Manager eScan ESET Security Frisk F-PROT Quick Heal Sophos Anti-Virus* VirusBuster 


* Default archive value exceeds chart area 
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| Archive scanning | | ACE | CAB | EXE-ZiP | Jar | L2H | RAR | TGzZ | zi | EXT 
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[1-9] - Archives scanned to limited depth; EXT* - Eicar test file with random extension; All others - detection of Eicar test file 
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embedded in archive nested up to 10 levels 


or on Samba shares only; for simplicity we opted to use this 
method, and again it proved simple to set up and configure. 


On-demand scanning speeds were pretty reasonable, and 
on-access overheads not too heavy, despite some pretty 
intensive default scanning levels. Detection rates were quite 
excellent, with the only problem encountered in the RAP 
sets, where a couple of files caused the engine to trip up with 
a segmentation fault error message. With these moved out 
of the way, RAP scores proved just as impressive as those in 
the main sets, and the clean sets threw up only a few (fairly 
accurate) warnings of potentially unwanted adware-type 
products (mostly toolbars included ‘free’ with some of the 
trialware products added this month). With no full blown 
false positives, and the WildList handled with ease, ESET 
earns another VB100 award to add to its impressive haul. 


Frisk F-PROT AntiVirus for Linux 
FileServers 6.3.3.5015 


Itw 100.00% Polymorphic 100.00% 
ItW (o/a) 100.00% Trojans 79.96% 
Worms & bots 100.00% False positives 0 


Frisk’s Linux 
product, like its 
Windows versions, 
is simple in the 
extreme, with most 
of it quite happy to 
run from wherever 
the initial zip is 
unpacked, but a 
Perl installer script is provided to simplify the 
set-up process. 
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RAP 64.7% 


Again, the choice of Dazuko or Samba-based on-access 
protection is offered, and again we opted for the Samba 
method as all on-access tests were being run from a 
Windows client. Everything was up and running fairly 
simply despite a lack of clear documentation. 


On-demand scanning speeds were excellent, and on-access 
overheads were not bad either. Detection rates proved 
decent, if not overwhelming. The clean sets and the 
WildList presented no difficulties, and as a result Frisk also 





earns itself another VB100 award. 
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Quick Heal for Linux 11.00 


tw 99.99% Polymorphic 100.00% 
ItW (o/a) 99.99% Trojans 87.75% 
Worms & bots 100.00% _ False positives 0 


Quick Heal’s product was one of 
few to have dependencies, in the 
form of a compatibility library 

for some older C++ code, but this 
presented little problem. Dazuko 
was the on-access filtering method 
of choice, with again a slightly 
different implementation, but it 
proved no problem to set up and get 
running. This needs to be done manually before the installer 
script is run, but with it in place everything else runs like 
clockwork, with helpful and descriptive comments and 
instructions provided. 


RAP 68.0% 


As ever, Quick Heal sped through the tests, with some 
superb times recorded in the on-access tests, the protection 
barely registering. This effect may have been helped by 

a lack of archive scanning on access — something which 
seemed impossible to activate in the rather minimal 
configuration system. Detection rates were pretty good 

on demand, although a notable difference between 
on-demand and on-access scores hinted at either wildly 
different settings or some stability issues with the on-access 
implementation. Further investigation and re-tests showed 








more variations in detection and speeds, with the protection 
appearing rather unstable on access. The fast speeds 
recorded may be a side effect of this uncertain application 
of scanning to files being rapidly accessed. 


Elsewhere, a fairly steep decline was observed across the 
RAP sets, although with a solid starting point the overall 
average was decent. The clean sets were handled accurately, 
but in the WildList set a single sample of W32/Virut, from 
the latest strain added to the list, went undetected both on 
demand and on access, and Quick Heal does not quite make 
the required grade for VB100 certification this month. 


Sophos Anti-Virus for Linux 6.7.3 


tw 100.00% Polymorphic 100.00% 
ItW (0/a) 100.00% Trojans 92.76% 
Worms & bots 100.00% False positives 0 


® 


Sophos’s product 
had one of the 
slickest installation 
processes, running 
smoothly and 
cleanly through 
the required 


VIRUS 
steps, including 


the selection and 


implementation of its own “Talpa’ on-access hooking set-up. 
With everything set up and operational in double-quick 
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Alwilavast! Avira AntiVir CA Threat Manager eScan * ESET Security Frisk F-PROT Quick Heal ** Sophos Anti-Virus VirusBuster ** 

* Default Linux file times exceed chartarea ** Archives not scanned internally 
time, testing sped through thanks to pleasantly sensible samples, we endeavour to capture copies of each sample 
and standardized command-line options for the on-demand with all the extensions it uses while spreading, to check for 
scanner, and a slightly more fiddly but well-documented just such errors. With several pieces of malware using this 
control system for the on-access component. extension to conceal spreading files from less sophisticated 


users, Sophos is lucky to have covered this month’s WildList 
without issues. As it is, several samples in the worms and bots 
set — all of which had been retired from the WildList in recent 
months — went undetected with the default settings. 


Scanning speeds were not bad in either mode, and detection 
rates proved very solid throughout the sets. However, a few 
anomalies were observed in the on-demand scan; relying 
on extension lists to decide whether or not to scan files, 

it appeared that at least one viable executable extension A VB100 award is earned, but we hope to see the error fixed 
had been missed off the list. When testing and replicating promptly. 


average aver. age 


CA Threat Manager 34.79% 35.10% 33.48% 34.46% 25.24% 32.15% 
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RAP detection scores — February 2010 


CONCLUSIONS 


This month we saw some products with 
tricky and esoteric installation and control 
systems among a field dominated by a 
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pleasant level of clarity and good design. 
We saw slow scanning times and heavy 





70.00% 


60.00% 


50.00% 


on-access lags, although most products 
were reasonably lightweight and nimble. 
We saw some disappointing detection rates 
alongside some highly impressive scores. 





40.00% 
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Reactive detection (average weeks -3 to -1) 


20.00% 


Having expected a high pass rate — perhaps 
even a clean sweep — we saw problems with 
false positives, missed polymorphic samples 
in the WildList set, and an unfortunate 
default setting causing products to miss the 





10.00% 


required standard for the award. All in all, a 
bit of a mixed bag. 
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A few interesting trends and patterns 
were noted. Unlike most of our tests on 
the Windows platform, where on-demand 
scores are almost invariably higher than 


90.00%  100.00% 








VirusBuster SambaShield for Linux 
1.2.1_3-1.2.2 4 


ItW 100.00% Polymorphic 89.10% 
ItW (o/a) 100.00% Trojans 88.90% 
Worms & bots 100.00% False positives 2 


As the name hints, VirusBuster’s 
SambaShield provides protection 
for Samba shares, which is just 
what is required for our test. The 
set-up process is simple and quick, 
with a nice installer script putting 
things in place and making the 
required tweaks to the Samba 
configuration file. Some rummaging 
around is subsequently required to find the scanner and 
other components. With these located, some fairly logical 
controls are provided for the on-access scanner, while the 
on-demand portion seemed less deeply configurable. 


PP 2 


RAP 69.4% 


Testing zipped along nicely, and scanning speeds were 
pretty good in general, although slower than many at 
handling the large number of small files in the Linux speed 
set. Detection rates showed further improvements to those 
noted in recent months, with a reasonable decline across the 
RAP sets. The WildList, with its many tricky Virut samples, 
was handled with aplomb, but in the clean sets a couple of 
files — one from Roxio and another from an AOL set-up CD 
— were alerted on as trojans, thus spoiling VirusBuster’s 
chances of a VB100 award this month. 





those recorded on access, we saw several 
products doing less well with their on-demand scans. This, 
of course, is due to the way the products are operated, with 
command-line scanners often defaulting to less thorough 
defaults than graphical ones, giving the operator more 
freedom and control to design scans as required. In the Linux 
context, the concept of ‘default’ is perhaps a little less exact 
than in most of our tests, although of course all scanners 
have their own list of automatically enabled options. 


The RAP tests produced some interesting results once 
again, with most products taking up familiar positions in the 
RAP quadrant. As our automation systems improve we are 
slowly increasing the size of the RAP sets, as well as fine- 
tuning their correlation with prevalence and telemetry data 
and thus their relevance, and hopefully this will continue to 
increase the value of the data provided. 


We also hope soon to implement a long-planned series of 
improvements in the polymorphic and worms-and-bots sets, 
as well as the redesign and rebuilding of our clean, speed and 
false positive sets. Much of this should be in place in time for 
the next test — for which we expect a vastly expanded field of 
products, including a number of newcomers. 


Technical details: 


All products were tested on identical systems with AMD 
Athlon64 X2 Dual Core 5200+ processors, 2GB RAM, dual 
80GB and 400GB hard drives. Test systems were running 


Novell SUSE Linux Enterprise Server 11, 32-bit edition, with 
Linux Kernel 2.6.27.19. On access tests were performed from 
clients running Microsoft Windows XP, Service Pack 3, accessing 
network shares exported using Samba 3.2.7. 
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END NOTES & NEWS 


RSA Conference 2010 will be held 1-5 March 2010 in San 
Francisco, CA, USA. For details see http://www.rsaconference.com/. 


The 7th Annual Enterprise Security Conference will take place 
3-4 March 2010 in Kuala Lumpur, Malaysia. For details see 
http://www.acnergy.com/EntSec2010.htm. 


Security Summit Milan takes place 16-18 March 2010 in Milan, 
Italy (in Italian). For details see https://www.securitysummit.it/. 


The 11th annual CanSecWest conference will be held 22-26 
March 2010 in Vancouver, Canada. For more details see 
http://cansecwest.com/. 


The MIT Spam Conference 2010 is scheduled to take place 25-26 
March 2010. For details see http://projects.csail.mit.edu/spamconf/. 


Black Hat Europe 2010 takes place 12-15 April 2010 in 
Barcelona, Spain. For details see http://www.blackhat.com/. 


The New York Computer Forensics Show will be held 19-20 April 
2010 in New York, NY, USA. For more information see 
http://www.computerforensicshow.com/. 


Infosecurity Europe 2010 will take place 27-29 April 2010 in 
London, UK. For more details see http://www.infosec.co.uk/. 


The 19th EICAR conference will be held 10-11 May 2010 in 
Paris, France with the theme ‘ICT security: quo vadis?’. For more 
information see http://www.eicar.org/conference/. 


The fourth annual Counter-eCrime Operations Summit (CeCOS 
IV) will take place 11-13 May 2010 in Sau Paulo, Brazil. For 
details see http://www.apwg.org/events/2010_opSummit.html. 


The International Secure Systems Development Conference 
(ISSD) takes place 20-21 May 2010 in London, UK. For details 
see http://issdconference.com/. 


NISC11 will be held 19-21 May 2010 in St Andrews, Scotland. 
Interest in attending can be registered at http://nisc.org.uk/. 


CARO 2010, the 4th International CARO workshop will take 
place 26-27 May 2010 in Helsinki, Finland. The workshop will 
focus on the topic of ‘Big Numbers’. For more information see 
http://www.caro2010.org/. 


Security Summit Rome takes place 9-10 June 2010 in Rome, 
Italy (in Italian). For details see https://www.securitysummit.it/. 


The 22nd Annual FIRST Conference on Computer Security 
Incident Handling takes place 13-18 June 2010 in Miami, FL, 
USA. For more details see http://conference.first.org/. 


The Seventh International Conference on Detection of Intrusions 
and Malware & Vulnerability Assessment (DIMVA) will take 
place 8-9 July 2010 in Bonn, Germany. For more information see 
http://www.dimva.org/dimva2010/. 


CEAS 2010 — the 7th annual Collaboration, Electronic messaging, 
Anti-Abuse and Spam Conference — will be held 13-14 July 2010 
in Redmond, WA, USA. A call for papers has been issued, with 

a deadline for submissions of 26 March. As in previous years the 
conference will run a ‘spam challenge’. For details see http://ceas.cc/. 


Black Hat USA 2010 takes place 24-29 July 2010 in Las Vegas, 
NV, USA. DEFCON 18 follows the Black Hat event, taking place 
29 July to | August, also in Las Vegas. For more information see 
http://www.blackhat.com/ and http://www.defcon.org/. 
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The 19th USENIX Security Symposium will take place 11-13 
August 2010 in Washington, DC, USA. For more details see 
http://usenix.org/. 


VB2010 will take place 29 September to 1 October 2010 in 
Vancouver, Canada. VB is currently seeking submissions from those 
wishing to present papers at the conference, see p.10. For details of 
sponsorship opportunities and any other queries relating to VB2010, 
please contact conference @ virusbtn.com. 
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